该agent用于服务间通信鉴权白名单， 既然是白名单模式，就必然是忽略鉴权。 由于是服务端之间使用，就是不推荐用户直接使用，因此不会在文档进行描述。

你这个问题就像nacos的默认管理员密码是nacos一样，因此你的修复建议无法采纳。

当然如果有更好的，不影响性能且不影响服务端间通信的修复方案，欢迎提出。

这个忽略鉴权，最大的问题是，没有在文档说明，对于大部分使用者来说，根本不知道会存在这样的一个机制（不看源码都不知道），虽说不推荐用户使用，但是这个机制默认就已经存在，等于是在用户毫不知情的情况下使用了，用户都不知道，何谈推荐不推荐呢。

我认为这个问题和nacos的默认密码是不一样的，用户在看到鉴权相关文档后，他自知自己开启了认证鉴权模式，那么，很大概率就知道需要修改账号密码（难道不是吗，账号密码我都不知道，我开启鉴权如何登陆控制台）。

我的修复建议是：

1. 默认关闭该机制，需要人工开启
2. 文档增加该方面的说明，并且建议“对于非服务间的通讯，过滤掉UserAgent Http header”

对于如何判断非服务间的通讯 有方法吗？ 如果能够判断服务间通信， 那我们也不用搞UserAgent了

这个忽略鉴权，最大的问题是，没有在文档说明，对于大部分使用者来说，根本不知道会存在这样的一个机制（不看源码都不知道），虽说不推荐用户使用，但是这个机制默认就已经存在，等于是在用户毫不知情的情况下使用了，用户都不知道，何谈推荐不推荐呢。

我认为这个问题和nacos的默认密码是不一样的，用户在看到鉴权相关文档后，他自知自己开启了认证鉴权模式，那么，很大概率就知道需要修改账号密码（难道不是吗，账号密码我都不知道，我开启鉴权如何登陆控制台）。

我的修复建议是：

1. 默认关闭该机制，需要人工开启
2. 文档增加该方面的说明，并且建议“对于非服务间的通讯，过滤掉UserAgent Http header”

本来就不是给用户用的而是自己内部使用的机制，在使用文档上说明不妥。用户不知道才是正确的。

欢迎社区提供方案：
方案如果能解决这个问题，并且满足下列条件

1. 不能影响服务端之间通信
2. 不能有太大的性能损耗
3. 低版本能够平滑过渡

社区非常愿意接受。

我想到一个方法，即能勉强解决问题，又不影响现有机制。

当前这个识别是通过User-Agent 是Nacos-Server来判断，比较固定。如果修改成key和value都由用户配置是不是就好了。默认还是User-Agent 是Nacos-Server。 如果有用户非要放外网环境，就让他自己设置这个内容。 key value都是他自己设置的。只有设置的人和正确设置的服务端能跳过鉴权。这样对内网环境用户升级就没有影响。继续用默认即可。

你的解决方式类似Http Basic Authentication，确实可行。建议当设置了用户自定义的key value后，默认的失效，而用户不自定义的话，就使用默认的User-Agent: Nacos-Server

还有，其实我觉得最重要的是让用户（指的是使用nacos的开发维护人员）知道有这个机制。

你的解决方式类似Http Basic Authentication，确实可行。建议当设置了用户自定义的key value后，默认的失效，而用户不自定义的话，就使用默认的User-Agent: Nacos-Server

还有，其实我觉得最重要的是让用户（指的是使用nacos的开发维护人员）知道有这个机制。

如果采用这种方式， 这个kv对的数量需要讨论下， 是只允许有一对，还是可以有多种。

目前想法是只有一对，User-Agent: Nacos-Server只是一个缺醒值，用户设置的话就覆盖掉了。

你的解决方式类似Http Basic Authentication，确实可行。建议当设置了用户自定义的key value后，默认的失效，而用户不自定义的话，就使用默认的User-Agent: Nacos-Server
还有，其实我觉得最重要的是让用户（指的是使用nacos的开发维护人员）知道有这个机制。

如果采用这种方式， 这个kv对的数量需要讨论下， 是只允许有一对，还是可以有多种。

目前想法是只有一对，User-Agent: Nacos-Server只是一个缺醒值，用户设置的话就覆盖掉了。

我认为一对可行，若是多对kv的话，说不定可以给企业用户带来更好的自定义扩展

后台应该还有类似的问题的其他接口，比如：

后台应该还有类似的问题的其他接口，比如：

尴尬不~~~~~~~~~~

NACOS1.1.4 fu x复现失败

NACOS1.1.4 fu x复现失败

鉴权功能应该是1.2.0才开始存在的，https://github.com/alibaba/nacos/releases/tag/1.2.0，https://github.com/alibaba/nacos/issues/1105

已经被RCE了，说不是漏洞？

好像这个问题影响还是挺大的，希望早点修复，因为动态配置的修改可能会导致其它的关联服务被入侵，比如spring application.properties里面的jdbc连接被改成恶意地址（h2）等等，会导致关联服务被执行恶意代码

公网搜了一下 90+开了公网. RCE+DB密码.... 直接脱库

#4683 临时处理了一下。
考虑到用户升级，默认开关是打开的，升级完成并设置统一key value后关闭开关后即可。

后续版本再想方案彻底移除吧

欢迎社区提供方案：
方案如果能解决这个问题，并且满足下列条件

1. 不能影响服务端之间通信
2. 不能有太大的性能损耗
3. 低版本能够平滑过渡

社区非常愿意接受。

ip白名单机制？

这种安全话题不适合公开讨论吧，nacos 没有 security 的 mailing list 吗？

consul 的 acl 就做的很好有角色分读写，开发者还是要提高安全意识，暴露到公网就相当于裸奔，太可怕了。

大家都信任 阿里大厂 才迁移到 nacos，何况很多小公司小团队安全意识淡薄，明星开源项目就更加要注重安全。

fastjson
nacos
阿里好样的

never mind scandal and liber. NMSL

我也来发表一下个人观点，仅供参考：

1. 从注册中心层面，例如，Eureka连注册中心都没有，很多公司也依旧在使用Eureka，并没有暴露出安全问题。如果黑客真的要攻击Eureka，那他获得的数据没多大的价值
2. 从配置中心层面，黑客攻击也许会有点点价值，但一般注重安全意识的公司，会加密脱敏一些重要的敏感数据，我个人认为加密算法应该是使用方自己去实现，不能是Nacos把算法通过开源方式提供
3. 落地Nacos还是需要使用者在安全机制上进一步自己增强，当然Nacos方法提供很优秀的安全解决方案则更好

上述观点仅供参考

从配置中心层面 apollo 都有权限验证，就算在配置了asm来脱敏一些信息， 我认为也需要鉴权。我算是明白了，为了快，安全都可以牺牲，fastjson是快了，nacos也是快了，结果裤子都被人脱了，🐎都被人日穿了

楼上说了很多，但是都没理解到nacos的意图，我做个分析。
分析了下Post的漏洞的代码，这块应该是做了两件事：

1. 对于访问nacos管理后台的请求进行拦截（以下简称：管理）
2. 对于微服务向nacos注册服务、心跳监控以及配置的请求不进行拦截（以下简称：服务）

对于微服务群来讲，所有微服务都是可信赖的，所以不需要认证，这个可以理解；而对于管理nacos来讲，管理端口通常会被暴露出来，所以需要认证的，这个也可以理解 ；造成这个漏洞的主要原因是将两者融合在一起。
解决的办法也是显而易见的：把这两个相关性不大的功能拆开
方案一：将管理和服务功能用不同的上下文来分离，可以参考actuator管理的实现方式
方案二：将管理和服务功能在路径上进行分离，管理路径要认证，服务路径不认证，文档上说明，暴露到公网时指定管理路径
如果我的理解有误，请帮忙指正 @KomachiSion

1. 如果仅是管理路径拦截，服务路径不拦截，可能很多非法的服务就能够注册订阅或者获取非法数据，如果没鉴权功能就算了，有鉴权的话还是要带上的。
2. 如果区分路径或者路径可配置，是不是api路径就会不稳定？那客户端可能比较难处理。
3. 如果需要区分的话，其实应该区分的是集群通信接口和客户端接口或openAPI，集群通信接口可以使用不同的方式进行鉴权。

我的理解Nacos就是属于一个内部型应用，不太会暴露在公网环境，请求基本都是可信环境的请求，目前的鉴权主要还是为了防止错用而影响其他应用，控制故障爆炸半径的思路去设计的。

这里的确是存在不少优化点，比如鉴权接口增加拓展性，以插件的形式接入，让社区安全大佬又更大的发挥空间，也让有强需求的用户能够对接他们认为安全的鉴权方式；2.0时候通过区分集群连接和客户端连接来进行不同的鉴权行为等。

主要问题点是大家对这个功能的理解不太一致，后续会在文档上补充说明。

该agent用于服务间通信鉴权白名单， 既然是白名单模式，就必然是忽略鉴权。 由于是服务端之间使用，就是不推荐用户直接使用，因此不会在文档进行描述。
你这个问题就像nacos的默认管理员密码是nacos一样，因此你的修复建议无法采纳。
当然如果有更好的，不影响性能且不影响服务端间通信的修复方案，欢迎提出。

回复所谓的“有没有更好的方案”这个问题

如果是要认证内部服务，有空可以读一下《HTTP API 认证术》
里面的HTTP Basic, OAuth/2的 Client Credential Flow可供借鉴。
这里的重点是——不要hard code，做成可配置的。

如果用白名单的话，那就应该直接用白名单的方式，
为什么要用User-Agent 这种Hack和“架飞线”方式？！
反问一下，对于白名单功能，你们能想到最好的方式就是用User-Agent ？

是的 其实是应该做成可配置的。 1.4.1临时修改了一下，做成可配置的了。看前面的讨论也是这个结论。

主要还是社区前人实现的时候定位Nacos是一个内网应用，不太会暴露在公网环境，请求基本都是可信环境的请求。从设计上是防止正常内部使用者误操作导致其他人的故障的思路去设计的。

该agent用于服务间通信鉴权白名单， 既然是白名单模式，就必然是忽略鉴权。 由于是服务端之间使用，就是不推荐用户直接使用，因此不会在文档进行描述。
你这个问题就像nacos的默认管理员密码是nacos一样，因此你的修复建议无法采纳。
当然如果有更好的，不影响性能且不影响服务端间通信的修复方案，欢迎提出。

回复所谓的“有没有更好的方案”这个问题
如果是要认证内部服务，有空可以读一下《HTTP API 认证术》
里面的HTTP Basic, OAuth/2的 Client Credential Flow可供借鉴。
这里的重点是——不要hard code，做成可配置的。
如果用白名单的话，那就应该直接用白名单的方式，
为什么要用User-Agent 这种Hack和“架飞线”方式？！
反问一下，对于白名单功能，你们能想到最好的方式就是用User-Agent ？

是的 其实是应该做成可配置的。 1.4.1临时修改了一下，做成可配置的了。看前面的讨论也是这个结论。

主要还是社区前人实现的时候定位Nacos是一个内网应用，不太会暴露在公网环境，请求基本都是可信环境的请求。从设计上是防止正常内部使用者误操作导致其他人的故障的思路去设计的。

这里有个场景：

1. A公司在内网部署了一套nacos，管理员B可以使用他的最高权限账号
2. 开发人员C把他的系统D接入了内网的nacos
3. 管理员B通过最高权限账号，分配了一个低权限账号E给开发人员C，只允许管理系统D的配置信息
4. 开发人员C鬼迷心窍，不使用账号E，在请求头加入UserAgent: Nacos-Server绕过了权限检查，通过内部网络任意访问nacos console中其他系统F、G、H...的配置，并且通过在配置中注入恶意代码，入侵其他系统

问题是，nacos的console设计，允许多用户、多角色、多权限，这是给人访问的，不是其他微服务，就算是内网，也是内部办公网可访问，办公网可访问的话，就一定不是可信的。这个问题的解决办法，就是分离console和config server。

大家都信任 阿里大厂 才迁移到 nacos，何况很多小公司小团队安全意识淡薄，明星开源项目就更加要注重安全。

其实很多暴露公网大部分都是大家测试用的，包括我们官网这个测试环境也是给大家测试， 大部分用户不会生产网暴露公网出来。

从我们角度看，哪个内部组件放到公网上一定都被黑客搞死的。 后面我们在产品文档中加强介绍生产网使用策略。

这种安全事件问题，在issues里面讨论真的好吗？ >_<

大家都信任 阿里大厂 才迁移到 nacos，何况很多小公司小团队安全意识淡薄，明星开源项目就更加要注重安全。

其实很多暴露公网大部分都是大家测试用的，包括我们官网这个测试环境也是给大家测试， 大部分用户不会生产网暴露公网出来。

从我们角度看，哪个内部组件放到公网上一定都被黑客搞死的。 后面我们在产品文档中加强介绍生产网使用策略。

您这个大部分简直太负责任了🐄🍺

如果文档里面没有提及这个问题，并且没有明确写出「不推荐把组建暴露到公网」的鲜明文案，那么用「大部分用户不会生产网暴露公网出来」这种所谓的行业习惯来混弄过关，不是蠢就是坏。
既然上面说的两点没有在文档中体现，那么这就是一个明显的BUG，老老实实承认不行吗？直接说明阿里的使用场景在内部，没有考虑到开源后各位使用者的不同使用场景就好了啊。
另外从技术卓越度来讲，即便是部署在内网的服务难道就不需要鉴权了吗？

其实很多暴露公网大部分都是大家测试用的，包括我们官网这个测试环境也是给大家测试， 大部分用户不会生产网暴露公网出来。
从我们角度看，哪个内部组件放到公网上一定都被黑客搞死的。 后面我们在产品文档中加强介绍生产网使用策略。

@yanlinly 不是，老板，这个如上面所说，办公网/内网搞事也很危险的啊。不然哪天可能有用户直接上新闻，员工删 Nacos 跑路了

举个例子，B 员工上内网服务器，curl 一下带个特定 UA，就能拿最高权限。对于没有内控内审跳板机等安全机制的中小企业来说删了数据还查不出人，这样非常非常危险的。

再举个攻击面

不过如上面用户所说，这种事情，建议开一个专门的 mailing list 讨论最好。建议官方后面删除这个 issue 或者做脱敏处理。

楼上说了很多，但是都没理解到nacos的意图，我做个分析。
分析了下Post的漏洞的代码，这块应该是做了两件事：

1. 对于访问nacos管理后台的请求进行拦截（以下简称：管理）
2. 对于微服务向nacos注册服务、心跳监控以及配置的请求不进行拦截（以下简称：服务）

对于微服务群来讲，所有微服务都是可信赖的，所以不需要认证，这个可以理解；而对于管理nacos来讲，管理端口通常会被暴露出来，所以需要认证的，这个也可以理解 ；造成这个漏洞的主要原因是将两者融合在一起。
解决的办法也是显而易见的：把这两个相关性不大的功能拆开
方案一：将管理和服务功能用不同的上下文来分离，可以参考actuator管理的实现方式
方案二：将管理和服务功能在路径上进行分离，管理路径要认证，服务路径不认证，文档上说明，暴露到公网时指定管理路径
如果我的理解有误，请帮忙指正 @KomachiSion

1. 如果仅是管理路径拦截，服务路径不拦截，可能很多非法的服务就能够注册订阅或者获取非法数据，如果没鉴权功能就算了，有鉴权的话还是要带上的。
2. 如果区分路径或者路径可配置，是不是api路径就会不稳定？那客户端可能比较难处理。
3. 如果需要区分的话，其实应该区分的是集群通信接口和客户端接口或openAPI，集群通信接口可以使用不同的方式进行鉴权。

我的理解Nacos就是属于一个内部型应用，不太会暴露在公网环境，请求基本都是可信环境的请求，目前的鉴权主要还是为了防止错用而影响其他应用，控制故障爆炸半径的思路去设计的。

这里的确是存在不少优化点，比如鉴权接口增加拓展性，以插件的形式接入，让社区安全大佬又更大的发挥空间，也让有强需求的用户能够对接他们认为安全的鉴权方式；2.0时候通过区分集群连接和客户端连接来进行不同的鉴权行为等。

主要问题点是大家对这个功能的理解不太一致，后续会在文档上补充说明。

回复1. 我指的是nacos的管理功能会通过nginx这种反向代理到公网上，那么在公网上肯定是需要做认证的，nginx不去代理服务的路径，就无法从公网去访问服务的数据或注册订阅，将管理和服务的功能区分开。我理解如果微服务能够集群在一起，这个集群的环境整体上是安全的，集群内部是可信的，不需要鉴权，增加鉴权反而降低了通信效率。退一步讲，集群环境中一个微服务出现安全问题，所有微服务都得跟着遭殃。
回复2.微服务注册的接口，订阅的接口以及配置中心的接口等等，用固定的就好，不用做的很灵活，这个是nacos client和nacos server之间的协议，一般也不需要使用者去修改。
回复3.我理解你说的集群通信接口和客户端接口应该是指nacos server和nacos client的角色，我所指的“服务”指的是nacos server和nacos client，“管理”指的是通过nacos的web界面，对注册到nacos的服务进行管理及配置。

既然提供了管理界面，相信大部分人都会将这个功能通过公网暴露出来，方便自己对微服务进行管理。所以内部型应用是一个初衷，当带上管理的帽子，加以鉴权的功能，那么这个初衷就不成立了。

另外从技术卓越度来讲，即便是部署在内网的服务难道就不需要鉴权了吗？

关于问题解决处理上面我已经回复我就不再次重复了。 我觉得内部组件不要暴露公网这个是一个常识。 我们是可以做好说明的，但是我不能阻断别人违背这个常识。 这个跟蠢跟坏没啥关系。

散了吧散了吧，越界了，受漏洞影响的用户，请升级到1.4.1版本https://github.com/alibaba/nacos/releases/tag/1.4.1，并且在conf/application.properties 配置中开启鉴权，以及启用新机制去避免被非法访问

nacos.core.auth.enabled=true
nacos.core.auth.enable.userAgentAuthWhite=false
nacos.core.auth.server.identity=aaa
nacos.core.auth.server.identity.value=bbb

恳请官方把我提的几个issue都做一下脱敏，或者删除吧，为何要通过issue提交安全漏洞，首先issue提交bug是惯例，其次最重要的是，除了温绍的fastjson、druid我可以找到ASRC报告以外，alibaba group中没有任何一个开源项目有security mail list。

还有，麻烦把这个issue也处理一下吧，最新机制的bypass
#4701

散了吧散了吧，越界了，受漏洞影响的用户，请升级到1.4.1版本https://github.com/alibaba/nacos/releases/tag/1.4.1，并且在conf/application.properties 配置中开启鉴权，以及启用新机制去避免被非法访问

nacos.core.auth.enabled=true
nacos.core.auth.enable.userAgentAuthWhite=false
nacos.core.auth.server.identity=aaa
nacos.core.auth.server.identity.value=bbb

恳请官方把我提的几个issue都做一下脱敏，或者删除吧，为何要通过issue提交安全漏洞，首先issue提交bug是惯例，其次最重要的是，除了温绍的fastjson、druid我可以找到ASRC报告以外，alibaba group中没有任何一个开源项目有security mail list。

忘了说，这个修复开启了也没用，#4701

这不是漏洞，这是后门。

严重同意@threedr3am 的观点，赶紧给删除或者脱敏。
目前安全公司已经全面向各公司曝出此漏洞，这个issue又教科书式的讲解如何进行复现。存在很大的风险：
1、@yanlinly 观点说不要暴露公网，即使在内网也不排除有内部员工，进行一些破坏性的操作导致配置被修改、业务不可用，且不可追溯作案人员，存在很大的潜在风险；
2、目前阿里的fastjson长期处于安全防护的重灾区，为此已投入了不少的整改成本；
3、目前国际形式惟恐不出安全问题，希望阿里大神们予以重视。

严重同意@threedr3am 的观点，赶紧给删除或者脱敏。
目前安全公司已经全面向各公司曝出此漏洞，这个issue又教科书式的讲解如何进行复现。存在很大的风险：
1、@yanlinly 观点说不要暴露公网，即使在内网也不排除有内部员工，进行一些破坏性的操作导致配置被修改、业务不可用，且不可追溯作案人员，存在很大的潜在风险；
2、目前阿里的fastjson长期处于安全防护的重灾区，为此已投入了不少的整改成本；
3、目前国际形式惟恐不出安全问题，希望阿里大神们予以重视。

@KomachiSion @yanlinly 麻烦项目管理员帮忙把issue内容进行一个删除

提一点，作为微服务框架这种平台性的东西，安全上最基本应当做到的就是”互不信任原则“，任何微 服务之间都应当假设彼此是不可信任的。这个公网内网没有任何关系。举个最简单的例子，如果平台上的一个低危低权服务出现rce漏洞或被实习生利用，是否整个平台上的服务都要跟着遭殃？

配合知道创宇端口扫描效果极佳，果然无聊的人不止我一个，在我眼皮子底下这台服务器就中招了，多了个用户

知道创宇总共搜出来了 800 多台 Nacos 服务器，提前默哀

严重同意@threedr3am 的观点，赶紧给删除或者脱敏。
目前安全公司已经全面向各公司曝出此漏洞，这个issue又教科书式的讲解如何进行复现。存在很大的风险：
1、@yanlinly 观点说不要暴露公网，即使在内网也不排除有内部员工，进行一些破坏性的操作导致配置被修改、业务不可用，且不可追溯作案人员，存在很大的潜在风险；
2、目前阿里的fastjson长期处于安全防护的重灾区，为此已投入了不少的整改成本；
3、目前国际形式惟恐不出安全问题，希望阿里大神们予以重视。

@KomachiSion @yanlinly 麻烦项目管理员帮忙把issue内容进行一个删除

安全问题不会因为删除而消失，只会因为删除而让受害者连排查问题都不知道从何做起、同时给能拿到0day漏洞的人更多可乘之机和提供更多信息不对等的机会。最好的方案是赶快发布漏洞声明、提交CVE、发布修复版本、利用github的security功能通知更多的使用者，而不是删除问题本身...

严重同意@threedr3am 的观点，赶紧给删除或者脱敏。
目前安全公司已经全面向各公司曝出此漏洞，这个issue又教科书式的讲解如何进行复现。存在很大的风险：
1、@yanlinly 观点说不要暴露公网，即使在内网也不排除有内部员工，进行一些破坏性的操作导致配置被修改、业务不可用，且不可追溯作案人员，存在很大的潜在风险；
2、目前阿里的fastjson长期处于安全防护的重灾区，为此已投入了不少的整改成本；
3、目前国际形式惟恐不出安全问题，希望阿里大神们予以重视。

@KomachiSion @yanlinly 麻烦项目管理员帮忙把issue内容进行一个删除

安全问题不会因为删除而消失，只会因为删除而让受害者连排查问题都不知道从何做起、同时给能拿到0day漏洞的人更多可乘之机和提供更多信息不对等的机会。最好的方案是赶快发布漏洞声明、提交CVE、发布修复版本、利用github的security功能通知更多的使用者，而不是删除问题本身...

受教了